正文

本系列已經邁入第七天了，之後也該開始講述 CI/CD 的實例，也會花比較多時間去研究如何建立 CI 的部分。在這之前，就先簡單聊聊我們預期透過 CI 系統去幫我們做到什麼吧。

昨天已經學習到了先在 Local 透過 Git Hook 幫我們做簡單的整合，但是不是每個人都會在 Local 進行這件事，所以在程式碼進主線時，我們仍要再做一次確保程式碼品質。

我們會預期任何要併入主線的程式碼，都應該通過單元測試，因為在執行 dotnet test 也隱含著 dotnet build ，所以也確保了程式碼是可以被建置的；兩者也都包含 dotnet restore，在相依性管理是否可正常下載套件也一起包含在裡面。

如果是直接讓開發者在主線上開發並且 Check-In，會讓程式碼沒通過品質檢測就進去，真的出錯了已經來不及了。所以我們要更改開發方式，任何變動都會先開啟一個短生命週期的分支，併透過 Pull Request (PR) 或是 Merge Request (MR) 的方式，將這個分支合併回主線。這樣我們就可以在 PR、MR 階段被 Approve 之前先透過 CI 進行檢測，若不通過則無法按下 Approve 的按鈕。

既然在這部分可以先停下來進行檢測，或許我們可以不只做單元測試，而可以做更多。但是為了避免每次提 MR、PR 都會因為等待 CI 時間過久，而導致團隊被 block 或是不耐煩，又必須讓這個流程不會超過一定時間，或許三分鐘內跑完整套流程是一個不錯的平衡，這就是一個提交階段的持續整合。

要讓速度快，我們就要研究如何讓 Runner 準備環境時盡量減少等待時間，如果是透過 Docker 建立 Runner，或許我們要研究避免每次都要重新 pull image，畢竟 .NET Core SDK 的 image 檔案也是超過 1024 MB 的巨大。或是我們能確保每次建置不會互相污染，直接準備一個已經存在的環境或許也是個嘗試方向。

在提交階段的持續整合，我會期待能執行冒煙測試，這樣至少就能確保這個程式是能正常運作的，所以也可以來研究要寫些怎樣的冒煙測試。快速且重要的驗收測試也是可以嘗試納入的。

另外，也會希望能在此階段與測試同時進行程式碼風格的檢測，若是團隊有嚴格規定程式碼風格，這時候若能用 Lint 工具幫我們找出變動的部分有不合規定的風格就幫了大忙了，我們就不用人工傷眼的逐一檢視，所以尋找一個合適的 Lint 也是我們接下來的研究目標。

除了程式碼風格，或許我們也能做點程式碼的靜態分析，給我們些指標和數據，像是測試覆蓋率、複雜度等等，讓我透過這些數據暸解程式碼品質的趨勢。或許我們不會嚴格因為數據下坡就不給予通過，但透過這些數據我們也能在我們心中留下一些警告，再有時間時趕緊還債。

接下來的一週，就先讓我們研究如何實現這些想要執行的檢測和分析吧！